寫在前面
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

Product 賣出去之後，Security Responsibility 到底要維持多久？
前面幾天一路談到 Risk Assessment、Secure Development、SBOM、PSIRT、Vulnerability Disclosure，這些事情其實都有一個共同問題：要做多久？
如果 Product 已經停產了呢？Warranty 已經結束了呢？Customer 卻還在繼續使用呢？
尤其是 Industrial Equipment、Automotive、Semiconductor 這類 Product，Lifecycle 往往非常長。這時 CRA 裡一個很重要的概念就出現了：Support Period。

一、先釐清：Support Period 不完全等於 Warranty Period
我一開始看到 Support Period，很容易把它理解成保固期，但仔細看 CRA，我覺得兩者最好不要直接畫等號。
Warranty 比較偏向 Contract、Commercial 或 Product Quality；Support Period 在 CRA 的脈絡下，主要則跟 Cybersecurity Support 有關，例如 Vulnerability Handling、Security Update、Product Security Monitoring 等。
所以，Product 保固三年，並不能直接推導 CRA Support Period 就是三年；反過來，CRA Support Period 也不代表所有 Hardware Warranty 都必須跟著延長。

二、CRA 是不是規定所有 Product 一律支援五年？
這題很容易被簡化成：「CRA 要求 Security Support 五年。」
但我自己現在不太會這樣說。
CRA Article 13(8) 的概念是，Manufacturer 要決定 Product 的 Support Period，而且原則上至少五年；但如果 Product 預期使用時間少於五年，Support Period 可以對應該 Product 的預期使用時間。
所以，五年是一個很重要的基準，但並不是所有 Product 不論情況都機械式套用五年。

三、反過來說，也不是「五年到了就一定可以停止」
這點我覺得更值得注意。
CRA Article 13(8) 要求 Manufacturer 在決定 Support Period 時，考量 User 的合理預期、Product Nature、Intended Purpose、Relevant Union Law，以及類似 Product 通常預期使用多久。European Commission 也可以透過 Delegated Acts，針對特定 Product Category 設定最低 Support Period。
所以，如果 Product 實際上通常會使用十年，Manufacturer 能不能只因為 CRA 有「五年」這個數字，就全部設定五年？我自己不會太快下這個結論。
還是需要回到 Product 的 Expected Use Time，以及 Article 13 所列的判斷因素。

四、這對 Industrial Product 就很有感
假設一台 Industrial Control Product，Customer 預期使用 10～15 年，而 Manufacturer 也知道這類設備 Lifecycle 很長。這時 Support Period 如果只設定五年，我自己會想再問一個問題：
這跟 User 對 Product 的合理預期一致嗎？
這不代表我認為一定必須支援 15 年，而是 CRA 本身就要求 Manufacturer 在決定 Support Period 時，考慮 Product 的 Expected Use Time。
所以，Support Period 其實開始變成 Product Lifecycle Management 的一部分。

五、那 Semiconductor 呢？
這題我自己特別有興趣。
一顆 Semiconductor 可能生產五年，但 Customer 把它 Design-in 到 Industrial Equipment，而 Equipment 使用十年以上。甚至 Semiconductor Manufacturer 停產之後，Customer 還有大量 Inventory。
這時 Product 的 Expected Use Time 到底怎麼判？
我自己目前不會只用 Production Period 來回答。因為「我們生產多久」跟「Product 預期被使用多久」可能是不同概念。
這部分我會希望 Product Team、Business、Legal / Compliance 與 Product Security 一起討論。

六、Support Period 應該在產品上市前就決定
CRA Article 13 要求 Manufacturer 在 Product Made Available on the Market 時，已經決定 Support Period，而且 Support Period 還需要包含在 User Information and Instructions 之中。
所以這不是 Product 上市五年後，才突然決定：「今天開始 EOL。」
而是 User 在取得 Product 時，就應該能知道 Manufacturer 預計提供 Cybersecurity Support 多久。
對我來說，這是一個滿大的 Product Lifecycle 觀念。

七、Support Period 內，Manufacturer 要做什麼？
我自己會把前面幾天談的內容全部拉回來。
Support Period 中，Manufacturer 仍需要持續處理 Product Cybersecurity，例如 Monitor Vulnerabilities、Handle Vulnerability Reports、Maintain relevant Product / Component Information、Assess Product Impact、Remediate Vulnerabilities、Provide Security Updates，以及在適當情況下更新 Cybersecurity Risk Assessment。
所以，Support Period 不只是官網寫一個日期。
背後其實代表的是：
公司承諾維持多久的 Product Security Capability。

八、Security Update 原則上要免費
CRA Article 13(9) 對 Security Update 有一個很重要的要求。
Manufacturer 應確保用來處理 Security Issues 的 Security Updates 在 Support Period 中免費提供，而且原則上要能與 Functionality Update 區分。
所以我自己會把 Security Fix 跟 Feature Upgrade 稍微分開思考。
例如，新功能可以有 Commercial Model；但如果是為了處理 Security Issue 所需要的 Security Update，CRA 有自己的要求。

九、Security Update 還涉及多久要保持可用
CRA Article 13(9) 也要求 Security Updates 在發布之後至少 10 年，或 Product 剩餘的 Support Period，兩者取較長者，保持可用。
這一點我第一次看到時其實滿意外。
因為 Support Period 跟 Security Update Availability 其實是兩個不同的時間概念。
例如 Product Support Period 結束，並不一定表示過去發布的 Security Update 就可以馬上從 Server 全部刪掉。

十、但「提供 Update」跟「Product 能不能 Update」又是另一題
Software 很容易理解：找到 Vulnerability，Patch → Release → User Update。
但某些 Hardware / Semiconductor 不一定存在可更新 Software。
例如 Silicon Design Vulnerability，Remediation 可能是 Firmware Mitigation、Configuration Guidance、Customer Workaround 或 New Revision。
所以我自己不會把 CRA Support Period 直接理解成：
每個 Product 都一定要有 OTA Update。
還是要依 Product Nature 與 Risk，看什麼方式可以合理處理 Vulnerability。

十一、CRA 也希望 Security Update 能更容易被安裝
Annex I Part I 提到，Product 應在適用情況下，透過 Automatic Security Updates 處理 Vulnerabilities。尤其 Consumer Product，Automatic Update 通常會是很重要的方向。
但我自己也不會把 Automatic Update 硬套在所有 Product。
例如 Industrial Control Environment 可能需要 Change Approval、Validation 及 Maintenance Window；Semiconductor 更可能根本沒有直接控制 Customer End Product Update 的能力。
所以：
where applicable
我覺得還是很重要。

十二、Support Period 其實也會影響 SBOM
假設 Product Support Period 是 10 年，那 Product Security Team 十年後還能不能知道 Product v1.3 用了哪個 OpenSSL、哪個 Firmware，以及哪些 Third-party Components？
如果 SBOM 只保存到 Product Release 後兩年，那後面的 Vulnerability Monitoring 可能就接不起來。
所以 Support Period 其實會反過來影響 SBOM Retention、Vulnerability Database、Product Configuration Record、Technical Documentation 等資料保存策略。

十三、也會影響 Supplier Contract
假設 Manufacturer 對 Customer 承諾 10 年 Security Support，但 Product 裡的 Supplier Component 只支援三年，那第四年 Supplier 出現 Vulnerability 時，誰來 Fix？
這可能就開始變成 Supply Chain Risk。
所以我現在覺得，Support Period 最好在 Supplier Selection 就開始考慮，包括 Supplier Support Lifecycle、Security Update Commitment、Vulnerability Notification、EOL / EOS Notice，以及 Source / Escrow Strategy（若適用）。
CRA 做到後面，很多事情真的會接在一起。

十四、EOL 也需要跟 Security Support 接起來
傳統 Product EOL 可能比較偏向 Last Order、Last Shipment、Replacement Product。
但 CRA 之後，我自己會希望多問一個問題：
Cybersecurity Support 什麼時候結束？
例如 Product EOL Date、Last Shipment Date、Support Period End Date，可能根本不是同一天。
這些日期如果 Product、Sales、R&D、PSIRT 各自有不同版本，未來 Vulnerability 發生時可能會非常麻煩。
所以我會希望 Product Lifecycle System 能有一個：
Security Support End Date。

十五、Legacy Product 可能才是最難的一題
新 Product 還可以把 CRA Requirement 放進 Development Lifecycle，但既有 Product 可能已經上市很多年，原 R&D 已經解散、Supplier 已經 EOL，甚至 Build Environment 都不存在。
但 Article 14 Reporting 在 2026 年 9 月 11 日就開始適用於相關既有 Product 情境。European Commission 目前也特別提醒，Reporting Obligations 會早於 CRA 全面適用日期開始。
所以我自己會覺得：
Legacy Product 值得另外盤點。

Day 12 小結｜Support Period 對我來說，是 Product Security 的「時間邊界」
研究到這裡，我自己已經不太把 Support Period 理解成「CRA 規定五年」，而比較像是：
Manufacturer 要合理決定：這個 Product 的 Cybersecurity Responsibility 要維持多久。
五年是重要的法規基準，但 Product Expected Use Time、Nature、Intended Purpose、User Expectation 等因素，也需要一起考量。
對 Semiconductor 來說，我覺得這題尤其值得討論，因為 Production Lifecycle、Customer Design Cycle、End-product Lifecycle 可能完全不同。
而 Support Period 一旦決定，後面會一路影響 PSIRT、Vulnerability Monitoring、SBOM、Security Update、Supplier Management 以及 EOL。
所以：
Support Period 可能不是 CRA Project 最後填的一個日期，而是 Product Lifecycle Strategy 的一部分。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
Support Period 的實際決定方式，還是應依 CRA Article 13、Product 特性、Expected Use Time，以及後續 Commission Guidance / Harmonised Standards 持續確認與調整。

Day 13 預告｜產品自己安全還不夠：CRA 怎麼把 Supplier 拉進來？
做到 Day 12，有一件事情越來越明顯：
Product 裡很多東西，根本不是 Manufacturer 自己做的。
Open Source 誰維護？Third-party SDK Supplier 支援多久？Commercial Library 出 Vulnerability 誰通知？Security IP 發現問題又該怎麼辦？
如果 Supplier 三年後停止 Support，但我們的 Product 還要支援十年呢？
Day 13，我們就來聊：
CRA、Third-party Component，以及 Product Security Supply Chain。